Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix various const eval errors #33339

Merged
merged 5 commits into from
May 5, 2016
Merged

fix various const eval errors #33339

merged 5 commits into from
May 5, 2016

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented May 2, 2016

These were found after const_evaluating arbitrary expressions and linting if the const evaluator failed

fixes #33275 (int -> float casts for negative ints)
fixes #33291 (int -> char casts (new! wasn't allowed in constants until this PR))

r? @eddyb

cc @bluss @japaric

Ok(Float(val as f64))
ty::TyFloat(ast::FloatTy::F32) => match val.erase_type() {
Infer(u) => Ok(Float(u as f32 as f64)),
InferSigned(i) => Ok(Float(i as f32 as f64)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reminds me, we need 2 variants, one for f32 and one for f64.

@japaric
Copy link
Member

japaric commented May 2, 2016

hmm... where's bors? or is @japaric not a reviewer?

I have r+ rights, but I think I'm not be registered with the highfive bot.

fixes #33291 (int -> float casts for negative ints)
fixes #33275 (int -> char casts (new! wasn't allowed in constants until this PR))

the descriptions seem to be backward.

@oli-obk r=me with added tests cases 😄.

There was no span available in the cast function, but we need to infer the `x` in `x as char` to `u8`.
The spans are now removed from all functions using `infer` and instead added in `eval_const_expr_partial`
@oli-obk
Copy link
Contributor Author

oli-obk commented May 2, 2016

the descriptions seem to be backward.

whoops :) fixed

added tests cases

hmm... when I tried to create a cfail test for the error message I found out that it's the wrong message and the wrong logic. It's not possible to cast anything but a u8 to a char. And the regular rustc error message even says so. So I made sure that the value is either a u8 or at least can be inferred into a u8. But that caused some fallout in the infer function, because the cast-function doesn't have a span, but the infer function expects a span to report any errors. I changed this to only return an ErrKind and to attach the span in eval_const_expr_partial.

Note that typeck catches this issue, so we can only test for the const_eval error message by evaluating a pattern or array length

@japaric
Copy link
Member

japaric commented May 2, 2016

It's not possible to cast anything but a u8 to a char. And the regular rustc error message even says so.

Oh, right. I didn't remember that was the case.

Note that typeck catches this issue, so we can only test for the const_eval error message by evaluating a pattern or array length

So typeck doesn't reject this cast when it's in an array length. That's ... interesting.

println!("{:?}", x);
}
const A_CHAR_USIZE
: [u32; 5u8 as char as usize]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay, more const casting possibilities.

@japaric
Copy link
Member

japaric commented May 2, 2016

@bors r+

Thanks @oli-obk!

@bors
Copy link
Contributor

bors commented May 2, 2016

📌 Commit ce6ea47 has been approved by japaric

Manishearth added a commit to Manishearth/rust that referenced this pull request May 3, 2016
fix various const eval errors

These were found after const_evaluating arbitrary expressions and linting if the const evaluator failed

fixes rust-lang#33275 (int -> float casts for negative ints)
fixes rust-lang#33291 (int -> char casts (new! wasn't allowed in constants until this PR))

r? @eddyb

cc @bluss @japaric
bors added a commit that referenced this pull request May 3, 2016
Rollup of 14 pull requests

- Successful merges: #33277, #33294, #33314, #33322, #33333, #33338, #33339, #33340, #33343, #33357, #33363, #33365, #33371, #33372
- Failed merges:
bors added a commit that referenced this pull request May 3, 2016
Rollup of 14 pull requests

- Successful merges: #33277, #33294, #33314, #33322, #33333, #33338, #33339, #33340, #33343, #33357, #33363, #33365, #33371, #33372
- Failed merges:
bors added a commit that referenced this pull request May 4, 2016
Rollup of 14 pull requests

- Successful merges: #33277, #33294, #33314, #33322, #33333, #33338, #33339, #33340, #33343, #33357, #33363, #33365, #33371, #33372
- Failed merges:
bors added a commit that referenced this pull request May 4, 2016
Rollup of 14 pull requests

- Successful merges: #33277, #33294, #33314, #33322, #33333, #33338, #33339, #33340, #33343, #33357, #33363, #33365, #33371, #33372
- Failed merges:
@bors bors merged commit ce6ea47 into rust-lang:master May 5, 2016
@durka
Copy link
Contributor

durka commented Jun 18, 2016

another one: b"x" as &[u8]

@oli-obk oli-obk deleted the fix/const_eval branch June 18, 2016 07:45
@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 20, 2016

@durka I can fix this easily. This is a mis-use of as, so we should probably start warning on it anyway

@durka
Copy link
Contributor

durka commented Jun 20, 2016

How is it a misuse? It's unsizing the &[u8; 1] to a &[u8]. But more than that, the message is bad -- it says "cannot cast this type" while the code compiles, so it certainly does cast the type, and it doesn't give the user any information about why the cast might be invalid.

@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 21, 2016

shouldn't a simple as_ref suffice?

#![feature(type_ascription)]

fn main() {
    let x = b"foo".as_ref();
    let y = x : &[u8];
}

I was under the impression that as should only be used for casting when there's no other way.

@eddyb
Copy link
Member

eddyb commented Jun 21, 2016

@oli-obk Calling as_ref in non-generic code is an anti-pattern. Also, it doesn't matter if as is bad style, sometimes it's the simplest option (given that ascription doesn't coerce).
&b"foo"[..] works but it's a bit uglier.
The problem is that the warning is wrong: the coercion/cast works fine, even if it's not implemented in const_eval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants